Pass the base menu bar (, File, Edit) to CASetMenuBar()
• Callback Handler Registration
• Document initialization
• Register floating windows via CARegisterFloatingWindow().
Storage
The CADocumentRef represent a distinct embedding unit. The CA may display a single container unit in one window at any given time. How a CADocumentRef maps to a CA document is CA dependent. A CA may store one CADocumentRef for each CA document (normal case), or multiple CADocumentRef’s for each CA document (multi-window documents).
For each embedded frame the CA is given a CAFrameRef with which to refer to that frame. The CAFrameRef referring to the root frame is a constant value. The CA needs to maintain content information (size, location, selection state, z-order, etc.) for each embedded frame. The CA should treat an embedded frame as a generic content element.
Event Processing
• Call CADispatchEvent() first. If false is returned then handle the event.
• Must call CADispatchMenuEvent() for menu events.
• Call CAAdjustMenus() when a mouse down occurs in the menu bar.
• Call CASetSelected() and CAGetSelected() appropriately.
The CA needs to handle the following new event types appropriately.
kCAEvtMouseDownEmbedded,
kCAEvtMouseUpEmbedded,
kCAEvtMouseUpBorder,
kCAEvtMouseDownBorder,
kCAEvtBGMouseDownEmbedded:
Although there are HI standards, how events are handled is very application specific.
Focus Tracking
The CA needs to maintain (via Focus callback handlers) which root part (CADocumentRef) owns the selection focus (NULL if an embedded part owns the selection focus). This is the only info the CA has concerning the current focus owner.
Callback Handlers (Required)
FocusLost()
• Clear current selection
• Set current focus owner to NULL (Embedded frame has focus)
FocusAcquired()
• Set current focus owner
• Set and display the application menu bar
WindowActivate()
• Activate events are not posted to the system event queue, window activation is handled
internally by the OpenDoc window state. This is the only notification the CA gets when a
window is activated or deactivated, actions for activation should be taken here (highlight, scrollbars, etc.)
FrameShapeRequest()
• Need to update internal data structures to reflect the new shape of an embedded frame.
Drawing
The CA needs to modify its Update procedure to draw embedded frames (CADrawFrame()) and the active border (CADrawActiveBorder()). Update events are not dispatched to OpenDoc, drawing embedded frames is the CA’s responsibility. Layering frames mixed with native content is controlled by the order in which they’re drawn.
Data Transfer
Scrap format
The CA needs to modify its clipboard and drag&drop procedures to appropriately interact with CALib. A total rewrite of the data transfer code will probably be beneficial in most situations.
The CA needs to define a new data transfer format (OSType) which represents the new data model of the CA, it must support CA native content plus embedded frames. This would parallel’s the part kind for a part editor/viewer version of the CA if one existed.
A scrap type of kCAScrapTypeODBentoContainer 'odcn' indicates that an OpenDoc container is on the clipboard. The document kind of the data transfer document indicates the part kind of the root of the container , the CA either incorporates the part contents (known part kind) or embeds the entire part (unknown part kind).
Sending (Copy, cut)
As opposed to writing to the system scrap, the CA now needs to write it’s scrap data to the target CALib data transfer document (via CAWrite()). The data flavor is specified by calling CASetDocumentKind() on the data transfer document. A limitation currently exists in CALib which limits the CA to a single data flavor .
Receiving (Paste)
If an OpenDoc container is present on the system scrap the CA reads the part content data using CARead() on the data transfer document. To embed the entire container as a part the CALib clone API can be used.
